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DUAL SOURCE REMITTANCE PROCESSING 



CROSS-REFERENCE TO RELATED APPLICATIONS 

This Application is related to U.S. Application Serial 
No ^ tW-VV^ ' filed^ M//?/?!^ , entitled AN ELECTRONIC BILL 
PAYMENT SYSTEM WITH MERCHANT IDENTIFICATION, and U.S. 
Application Serial No- ^^^^ , filed^^ entitled 
AN ELECTRONIC BILL PAYMENT SYSTEM WITH ACCOUNT RANGING, U.S. 
Application Serial No £iled ^y^^^^' entitled 

AN ELECTRONIC BILL PAYMENT SYSTEM WITH ACCOUNT NUMBER SCHEMING 
which are filed simultaneously with this application. 



FIELD OF THE INVENTION 

The present invention relates to electronic commerce. 
More particularly, the present invention relates to an 
improved electronic bill payment system. 
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BACKGROUND OF THE INVENTION 

It has been common for many years for consumers to pay 
bills by way of a personal check written by the consumer to 
the order of an entity and delivered to that entity by mail or 
5 in person. With the proliferation of computers interconnected 

to computer networks, particularly the Internet, consumers can 
now pay bills electronically. However until recently it was 
"~ not possible for a consumer, using a computer terminal, to 

: : . a 

h interact with a single payment system capable of paying all 

i: 0 10 the consumer's bills whether by electronic means or by a paper 

:.L check. Such a system now exists in the form of a consolidated 

r i 

ifu bill payment system as described by Right, et al. in U.S. 

sfl Patent No. 5 ,,383, 113, entitled SYSTEM AND METHOD FOR 

S • 

ELECTRONICALLY PROVIDING CUSTOMER SERVICES INCLUDING PAYMENT 

15 OF BILLS, FINANCIAL ANALYSIS AND LOANS. 

Although the consolidated bill payment system described 
by Kight , et al . significantly advanced the state of the art, 
it did not focus on several problems which may arise in 
implementing a consolidated bill payment system capable of 

20 automatically paying consumer bills to merchants. 
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A typical state of the art electronic bill payment 
system is established by a financial institution or third 
party to provide subscribing customers with the capability 
to electronically pay registered merchants. Present day 
5 electronic bill payment systems operate in an integrated 

manner to collect payment requests electronically from 
^ consumers, process those requests to render them suitable 

~2 for payment, and then pay the registered merchants, i.e., 

O merchants listed in the system database. Hence, using 

*JP 10 present day systems, each has to establish relationships 

i! 5 I 

;L with both customers and merchants. 

j^tj Developing and implementing a bill payment system has 

«|j significant costs. First, a relationship has to be 

established with each merchant. Furthermore, special 
15 formatting requirements, and other rules and procedures 

required by each merchant for presenting payment data in a 
form the merchant system can process automatically must be 
determined and complied with. One of the features most 
desirable in any consolidated electronic bill payment system 
2 0 is that a consumer be allowed to pay any merchant to which 
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the consumer owes a bill. Ultimately, this means that each 
conventional bill payment system may have hundreds of 
thousands of merchants in a database. Each bill payment 
entity must establish relationships with these merchants and 
5 comply with their special rules and procedures for the 

transfer of payment data. This is an expensive and time 
consuming process. Thus, it would be beneficial to provide 
~ a way to reduce the time and expense which must now be spent 

q by every bill payment entity to implement a consolidated 

?.y 10 bill payment system. 

* l Another problem is that consumers or data entry 

L= personnel sometimes make mistakes in entering payment data 

Iq required by the bill payment system. Such a case arises when 

a consumer's account number with a merchant is incorrectly 
15 entered. The payment system must submit a correct account 

number to the merchant who will use this account number to 
associate the payment with the consumer. Thus, a technique 
is needed to validate the submitted consumer's account 
number . 
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A data entry person may also enter payment data which 
incorrectly specifies the merchant's name or parts of the 
merchant's address. It has been found that merchant 
information such as the merchant name, address, zip code are 
5 typically mangled at the data entry stage. It has been 

further observed that errors will often be made upon entry 
of the zip code. The merchant's name, address, and zip code 
is typically required by the payment system in order to, for 
q example, retrieve merchant records from the merchant 

*-0 10 database. If this data is incorrect, the payment system may 



be unable to retrieve the correct merchant's record for 



processing a payment. Thus, a technique is needed to 



correctly identify a merchant record notwithstanding the 



submission of erroneous merchant data. 



15 



A consolidated bill payment system must also have the 



capability to properly remit payments to the same merchant 



at more than one remittance center. Commonly a large 



commercial merchant, (e.g 



* / 



shoe company, Sears) will have 



several remittance centers distributed geographically so 



20 



that customers can submit bills to a center within their 
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location. Thus, a technique is required to ensure that 
consumer payments are remitted to the proper one of multiple 
remittance centers associated with the same. 

Advantageously, a consolidated payment system must also 
5 be able to handle the different processing formats and 

requirements of numerous separate merchant accounting 
systems. For example, each merchant's account system may 
require payment information, such as consumer account 
numbers, in a format different than that submitted by the 

10 consumer. For. example, many merchant accounting systems 

will only accept an account number with some portion of a 
consumer's last name or the consumer's zip code appended to 
the end of the account number presented by the customer. 

A merchant account system may even require an altered 

15 consumer account number which uniquely identifies the 

consumer. For example, two consumers, e.g., spouses, may 
have identical account numbers, but the merchant accounting 
system may designate the account of each consumer uniquely, 
such as by combining the account number with the prospective 

20 customer's name. Additionally, it is not unusual for a 
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merchant to have different account numbers for a single 
customer. For example, an account number on an invoice 
which goes out electronically may be different from an 
account number for the same customer which goes out as a 
paper transaction. 

Thus, a consolidated bill payment system must be able 
to handle the various formats required by the merchant 
accounting system of each merchant. Accordingly, a 
technique is required to transform payment data received 
from the consumer into a form compatible with a merchant's 
accounting system. 

Objectives of the Invention 

Accordingly, it is an object of the present invention 
to provide an improved technique for automatically paying 
bills to any merchant on behalf of consumers. 

It is a further object of the present invention to 
provide a technique which allows individual bill payment 
entities to implement consolidated bill payment system with 
greater efficiency. 
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It is a further object of the present invention to 
provide a technique for correcting erroneous bill payment 
data received from customers. In particular, it is an 
object of the present invention to correctly identify a 
5 merchant record based on received information which may 

include erroneous data. 

It is still a further object of the present invention 
to provide a technique for furnishing payment information, 
including a payor's account number with a merchant, in a 
10 format acceptable to a particular merchant's accounting 

system. 

It is another object of the present invention to 
provide a technique for validating a consumer's account 
number with a merchant . 
15 It is another object of the present invention to 

provide a technique for ensuring payments are remitted to 
the proper remittance center. 

Additional objects, advantages, novel features of the 
present invention will become apparent to those skilled in 
20 the art from this disclosure, including the following 



IPDC.-781.1 33500-00004 



Docket No.: 33500-00004 

detailed description, as well as by practice of the 
invention. While the invention is described below with 
reference to preferred embodiment (s) , it should be 
understood that the invention is not limited thereto. Those 
of ordinary skill in the art having access to the teachings 
herein will recognize additional implementations, 
modifications, and embodiments, as well as other fields of 
use, which are within the scope of the invention as 
disclosed and claimed herein and with respect to which the 
invention could be of significant utility. 

SUMMARY OF THE INVENTION 

In order to solve the limitation of present art 
electronic bill payment systems, the present invention 
provides a method and apparatus for electronically 
processing bill payment requests where respective sets of 
payment requests are received electronically from a 
plurality of independent sources, each set of payment 
requests corresponding to an associated set of payors 
requesting payments to a plurality of payees. The payment 
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requests are processed at a single remittance processing 
system having a database including payee information for 
each of the plurality of payees to generate payment 
directions for paying the plurality of payees in accordance 
5 with the processed payment requests. 

A source may include any computer or network of 
computers capable of collecting payment requests from 
consumers, and may be, for example, a CheckFree processing 
center, a financial institution, or some other payment 

10 processing center. Typically a payment request would be a 

record containing whatever information is needed to process 
a particular payment. 

Beneficially, the sets of payment requests from payors 
are sent from the sources to the bill payment system as 

15 batch files. Preferably, the bill payment system can 

normalize batch files received from the sources to 
correspond to a single normalized format. 

In yet another aspect of the present invention, each of 
the received payment requests includes payor payment 

20 information, and the payment information other than a 
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received zip code is processed to identify an eleven digit 
zip code for the payee to be paid. The database is then 
accessed by the eleven digit zip code to locate payee 
information on the payee to be paid. 

In a still further aspect of the present invention, a 
payee has a plurality of payment remittance centers and a 
payment request includes information identifying a payor 
account number with the payee. The account number is 
processed to select one of the plurality remittance centers 
and payment is directed to the selected remittance center 
for the payee . 

In a further aspect of the present invention, each of 
the payment requests includes a payor's account number with 
a payee. Alteration rules are stored corresponding to a 
payee account number format and one of the received account 
numbers is transformed into an altered account number 
according to the alteration rules. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a system overview of an automated bill 
payment system in accordance with the present invention. 

FIG. 2A is a diagrammatical representation of an 
electronic bill payment system according to the present 
invention. 

FIG. 2B is a diagrammatical representation of an 
electronic bill payment system according to the present 
invention . 

FIG. 3 is a flow chart illustrating merchant 
identification in accordance with the present invention. 

FIG. 4 is a block diagram illustrating accesses to the 
merchant database during merchant identification in 
accordance with the present invention. 

FIG. 5 is a flow chart illustrating account ranging in 
accordance with the present invention. 

FIG. 6 is a flow chart illustrating account scheming in 
accordance with the present invention. 
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PREFERRED EMBODIMENT (S) OF THE INVENTION 

FIG.l generally depicts a bill payment system including 
consumer systems (i.e., payors) 8, merchant systems (i.e., 
payees) 4, source systems 7, a remittance payment processor 
(RPP) 3, merchant bank systems 5, and consumer bank systems 
6. 

A consumer system 8 provides the consumer (i.e. payor) 
with an interface to the RPP 3 via a source system 7 and 
typically would be a personal computer located at the 
consumer's residence, but could possibly be another 
electronic device such as a phone or specialized box 
containing bill payment software. A consumer is an 
individual or other entity, e.g., a corporation, for whom 
payments are actually made and whose account will be debited 
by the amount of the payment . 

Source systems 7 represent any computer or network of 
computers capable of collecting payment requests from one or 
more consumer systems 8, and may be, for example, a 
CheckFree processing center 7B, a financial institution 
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processing center 7A, or a third party payment processing 
center 7C. 

Merchant systems 4 are computer systems typically owned 
by merchants for carrying out the bill payment process. 
Merchants are the persons or other entities to whom payments 
are made via the bill payment system on behalf of consumers. 
Merchants may include department stores, the phone company, 
the paper boy, a credit card company, as well as other 
persons and entities to whom payments are owed by one or 
more of consumers. Merchants have accounts with merchant 
bank systems 5 to which payments made on behalf of consumers 
are forwarded for deposit. 

Consumer bank systems 6 either physically or 
electronically hold funds on account for consumers. These 
accounts are debited by the amount of any payments made to 
merchants on behalf of the consumers. 

A network 1 connects the above- stated entities making 
communications between them possible. The network may be of 
any type capable of facilitating the flow of information 
among the various entities. It could, for example, be a 
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public telecommunication network, the Internet, or other 
type of communication network. The network 1 may also be 
physically realized as one or more private or public 
networks. For example, in one possible embodiment, consumer 
5 systems 8 are coupled to a source systems 7 through one 

network and the source coupled to the RPP 3 through another 
separate network . 

FIGS. 2A-2B illustrate an overview of the process flow 
of a bill payment system. As shown in FIG 2A, source 
10 systems 7A-C collect payment requests from consumer systems 



8A-8C over networks 1A-1C. Typically, each source has its 



own consumer base of subscribed consumers. Thus, Referring 



to Figure 2A, Bank Source System 7A collects payment 



requests from consumer system Al through consumer system AN, 



15 



denoted as consumer systems 8A, where there are N subscribed 



consumers, over network 1A. Similarly, CheckFree Source 



System 7B collects payment requests from consumer system Bl 



through consumer system BM, denoted as consumer systems 8B, 



where there are M subscribed consumers, over network IB. 



20 



Similarly, Third Party Source System 7C collects payment 



IPDC:781.1 33500-00004 



15 



Docket No. : 33500-00004 

requests from consumer system CI through consumer system CP, 
denoted as consumer systems 8C, where there are P subscribed 
consumers, over network 1C. 

In Figure 2A, each source is depicted as receiving 
payment requests from consumers over its own wide area 
network 1A-1C. However, other network configurations are 
possible. For example, the payment requests could be 
received over a single network, such as the Internet. 
Furthermore, the networks may be private or public (e.g., 
the Internet) . 

A payment request contains payment information for a 
consumer which will include several different types of 
information, such as the consumer account number, the 
merchant name, and the merchant address. 

RPP 3 receives payment requests from each of the 
sources 7A-7C via networks 1D-1F. Typically, each source 
collects the payment requests, processes the requests into 
batch files, and transmits the batch files over networks 1D- 
1F. In FIG 2A, each source is depicted as connected to the 
RPP 3 shown in FIG 2B over a wide area network. However, 
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other network configurations are possible including the 

possibility that networks ID- IF are a single network, and 

the networks may be private or public (e.g., the Internet) . 

The RPP 3, as further detailed in Figure 2B, includes a 
5 memory 16 storing programmed instructions for carrying out 

the functions of the RPP, a processor 17 for executing these 
. & instructions, and a merchant database 18 storing information 

associated with the merchants 4. 
Q RPP 3 includes an input port 10 which accepts and 

^ 10 collects together the payment requests from each of the 

respective sources 7. Preferably, RPP 3 also includes a 
jtj normalization unit 9 which accepts the collected payment 

O requests from input port 10, each payment request in a 

particular source's format and automatically converts the 
15 received format to a format compatible to the RPP 3. Thus, 

each source does not have to alter its own formatting or 

procedures in order to have payment requests processed by 

the RPP 3. 
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The RPP 3 processes the received payment information 
from the payment requests, and passes payment instructions 
to a merchant payment processing system 25 which processes 
the payment instructions in processor 24 in accordance with 
programmed instructions on memory 23, and makes payments to 
merchant systems 4 either directly or indirectly. It should 
be understood that the merchant payment processing system 25 
could be multiple systems which respectively reside with 
each source 7, a single system (as shown) which resides with 
the RPP 3 or as a separate stand-alone system controlled by 
an entirely separate entity connected to the RPP 3 by a 
network. Hence each source processing system 7 collects 
payment requests made by consumers in its consumer base and 
the one or more merchant payment systems 25 makes payments 
on behalf of these consumers 8 in accordance with payment 
directions from the centralized RPP 3 . 

Payment is made from the payment processor 25 to 
merchant system 4 or merchant bank system 5 electronically 
through networks 1G-1J, or alternately can be transmitted by 
paper through checks 32 and drafts 34. Payment advice 
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reflecting the payment can also be directly sent by network 
1G to merchant system 4. The payment information is 
presented to the applicable merchant electronically in a 
form that the merchant system 4 can process to update the 
5 merchant ' s records . 

As shown in Figure 2B, one possible mode of payment to 
a merchant via merchant bank 5 is electronic funds transfer 
through the Federal Reserve Automated Clearing House (ACH) 
Network 1H. Another electronic payment avenue is through 

10 the MasterCard RPS Network U. Additionally, payment can 

also be made non-electronically to a merchant by a check 3 2 
or a draft 34 printed on laser printer 28. Payment advice 
can alternatively be delivered through Fax 22 or through the 
telephone network II. Thus, by the above described process, 

15 the bill payment system of the present invention pays bills 

to merchants according to payment requests received by 
customers through multiple sources. 

Now taking a closer look at the RPP processor 17, the 
RPP„ stores or processes several different record types 

20 necessary to the bill payment process. A merchant record 
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contains all necessary information needed to forward a 
payment. This includes a merchant name, address, and zip 
code. A consumer record includes a consumer name, address, 
zip code, and consumer account number. A payment record 
5 will contain information related to payment, including payee 

identification, consumer identification, and the dollar 
amount of the transaction. The merchant records are stored 



in a merchant database 18. All other records as well as 



programmed instructions which direct the operation of the 



iQ 10 



RPP are stored in a memory 16. The memory 16 could also 



store the merchant database 18 if desired. 



After receiving payment requests from sources 7, the 



RPP 3 periodically initiates a payment cycle 20 which 



process the records to generate information which will be 



15 



used by the payment processing system 25 to credit merchant 



accounts and advise the merchant systems of the payments. 



The processing flow of the billing cycle contains, in 



addition to other processes, three particularly important 



processes necessary for successful processing of each 



20 



payment request. These processes are merchant 



IPDC: 781.1 33500-00004 



20 



t 



Docket No.: 33500-00004 

identification 19a, account ranging 19b, and account 
scheming 19c, typically performed in this order. In the 
first step of processing a payment request, the processor 17 
attempts to identify a merchant in the merchant database 18 
5 based on information in the payment request. In the second 

step, the processor 17 will attempt to determine a 
remittance center of the merchant to which the payment 
^j. and/or payment information is to be sent. If a candidate 

Q remittance center is identified, the system enters the third 

10 stage of processing, account scheming. In account scheming, 

i.jj 

^ the processor 17 attempts to normalize a user account with a 

Ify merchant according to the merchant's rules. If account 

r fl scheming fails, the system will return to the account 

ranging process to attempt to identify another candidate 
15 remittance center, and from there, again into account 

scheming. 

Although the above described payment cycle is a 
preferable embodiment of the RPP, a payment cycle can 
include merchant identification 19a, account ranging 19b, 
20 and/or 19c, in any order or combination. In addition, these 
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processes may be performed independently, and could be 
performed individually outside the RPP. These three 
processes will now be described in further detail herein 
referring to FIGS 3-6. 
5 FIG. 3 illustrates merchant identification. Using 

merchant identification, the RPP 3 is able* to retrieve the 
correct merchant record from merchant database 18 based on a 
consumer's payment request submitted with possibly erroneous 
merchant name and address information, e.g., street address, 
^ 10 city, state, zip code. It has been observed that data entry 

q operators will often make errors in the merchant's street 

it! address and zip code. The RPP 3 is capable of mapping the 

■0 mangled merchant information supplied in the payment request 

into the proper merchant record in the merchant database 18 
15 notwithstanding the errors in the merchant information. 

Merchant identification as described herein, can be used in 
any implementation where merchant information is likely to 
contain errors and must be mapped into an existing merchant 
record in the merchant database. 
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RPP 3 initiates merchant identification by step 60 
which retrieves a payment record from one of the payment 
records previously submitted by the source 7. At step 62, 
the RPP first attempts to retrieve a merchant record from 
5 the merchant database 18 by matching the merchant id 

included in the payment record against the records of the 
merchant database 18. If there is a match, then at step 63 
processing of the payment record continues to the payment 
directions stage 64. The payment directions stage is where 

10 the RPP determines where to send payments. This stage 

includes account ranging discussed below which determines 
the remittance center to which payment gets sent. If there 
is no match at step 63, the RPP continues to step 65. At 
step 65, the RPP maps the merchant's merchant name and 

15 address, excluding the provided street address and zip code, 

into an eleven digit zip code. That is, the RPP produces an 
eleven digit zip code based on merchant name, city, and 
state in the payment information. In order to avail the 
merchant information which the inventors have determined to 

20 be mostly likely to contain errors, the received merchant 
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street address and zip code are not considered. Hence, in 
step 65 the RPP 3 identifies an eleven digit zip code based 
only on the merchant's name, city, and state. 

Step 65 of merchant identification uses the indexing 
structure shown in Figure 4 to access one or more records 
from the merchant database 18. In step 65, referring to 
FIG. 4, the RPP 3 forms an 11 digit zip code index 82 and 
compares this index to index 84 in order to retrieve a 
merchant record in merchant database 18. It may be possible 
that there is more than one merchant at a location 
identified by an eleven digit zip code. For example, there 
could be a remittance processing center on the floor of the 
building identified by the eleven digit zip code which 
handles payments for several merchants 4. In such a case, 
the RPP differentiates the correct merchant record from 
other possibly correct merchant records associated with the 
same eleven digit zip code by, after identifying merchant 
records indexed to the same eleven digit zip code, comparing 
some portion of the merchant's name, e.g., the first five 
characters with the characters of each merchant's name which 
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has been combined with the application zip code in the 
merchant index. The RPP 3 is thereby able to uniquely 
identify the proper merchant record. 

If step 65 identifies a unique merchant record then 
there is an exact match and at step 66 processing continues 
to step 64. However, if step 65 retrieves more than one 
merchant forming a group of records 86, (see FIG 4) then at 
step 66 processing continues to step 67. At step 67, the 
RPP 3 will attempt to match one or more characters of the 
merchant's name 83 against the records 86 to identify a 
merchant record. If a match is found, processing continues 
at step 68 to the payment directions stage 64.' If there is 
no match, then at step 68 the program will continue to step 
69 where the RPP will handle the unmanaged merchant. If 
there is no merchant, the system may have provisions at step 
69 for adding the merchant to the merchant database 18. 

FIG. 5 illustrates a payment direction stage, as 
performed in the preferred embodiment of the present 
invention, in which the RPP attempts to determine a 
remittance center to which payment is sent. The RPP 
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determines a remittance center based on one or more of the 
following identification rules: 1) length of account number, 
2) merchant zip code, 3) merchant name, and 4) account 
ranging. Each rule has in common that it identifies the 
remittance center based on some factor of the payment 
information . 

In Figure 5, the RPP 3 processes the payment record 
presented in step 51 to determine one of a plurality of 
remittance centers associated with the applicable merchant 
in which to make payment. In step 53, the RPP chooses one 
of the above-mentioned four rules and at step 55 attempts to 
identify a remittance center. If a remittance center is 
found at step 56, then the RPP directs payment to that 
remittance center 58. If the RPP is unsuccessful in 
determining a remittance center, the RPP cycles back to step 
53 and picks a new rule for identification. By this 
process, the system cycles through all combinations of rules 
that identify remittance centers for the merchant. 
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In account ranging, the correct remittance center is 
determined based on some characteristic of the consumer's 
account number. Typically a large merchant, such as credit 
card company will have multiple remittance centers to which 
5 respective consumer payments must be submitted. The payment 

record contains information which may be used to identify a 
remittance center besides an account number, such as an area 
O code of the payor's telephone number. A telephone phone 

IT utility might include each consumer's area code in the 

q 10 consumer's account number and require payments from all 

consumers within a particular area code be directed to a 
particular one of multiple remittance centers. A credit 
card company may require that payments from all consumers 
having the same first six digits in their account numbers be 
15 made to the same remittance center. 

The payment direction process illustrated in Figure 5 
is a preferred embodiment for determining payment direction. 
In this embodiment, the payment direction process includes 
account ranging as one of four possible methods of 
20 identifying a remittance center. However, in other 



In 
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embodiments, account ranging may be used in different 
combinations, or independently. 

FIG. 6 illustrates the steps for account scheming. In 
certain cases, the consumer account number received by the 
5 RPP as part of the payment information may contain errors. 

Hence, the RPP has no way of checking the account number 
against a previously stored account number associated with 

? S the applicable consumer to verify the accuracy of the 

O ■ 

l Z received information. 

Iq 10 Using account scheming, the RPP receives, in step 12a, 

•<* the consumer account number as part of the payment record. 

a 

In step 42, the RPP checks to validate the account number. 
=Q Then in step 46, the RPP alters the account number to 

correspond to a format required by a merchant's system 4 for 
15 processing. 

More particularly, the RPP validates and alters the 
consumer account number by storing separate business rules 
for each merchant which identify the expected general format 
for any consumer account number associated with that 
20 merchant. These business rules are stored as validation 
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templates 40 in merchant database 18 for each merchant. The 
account number received from the consumer is checked against 
the validation template to validate that the account number 
conforms to the general account number format to which an 
5 account number associated with the applicable merchant must 

conform. For example, the validation template for a 
merchant such as a credit card company may require an 
account number begin with the numbers "43" and be 18 digits 
long. Additionally, for some merchants the validation 

10 template will have check digit requirements. That is, the 

validation template can be used to confirm that the received 
consumer account number conforms to a check digit after 
being run through a specific algorithm. 

In operation, the RPP 3 performs, in accordance with 

15 programmed instructions stored on the memory 16, the 

validation procedure by comparing in step 42 the received 
consumer account number for the applicable merchant received 
in step 12a with the validation template, say 40, for that 
merchant to test the validity of the account number. If 

20 that account number is not valid, the payment directions are 
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rejected as not valid in step 43; otherwise, the account 
number is considered valid. 

Once the account number has been validated, it is then 
modified in step 46 so as to conform to alteration rules 44 
for the applicable merchant. The alteration rules 44 are 
also stored in database 18. The alteration rules 44 relate 
to the format of the consumer's account number in which the 
applicable merchant system requires to process a consumer's 
payment. Typically, alteration rules would specify an 
altered account number which includes a portion of a payor's 
name with the account number, a portion of the payor's 
address with the account number, or a portion of the payor's 
zip code with the account number. Alteration by the RPP 3 
involves notifying the received account number which will be 
furnished, along with payment, to the merchant. For 
instance, some merchant systems require that the consumer's 
account number always end in u 120". Hence, in such a case, 
the RPP 3, in accordance with programmed instructions stored 
on the memory 16, modifies the received account number to 
append "120" to the end of the alpha-numeric sequence of the 
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received account number. Once the account number has been 
modified so as to conform to the format required by the 
merchant system, the altered account number 47 is then 
transmitted from the RPP 3 to the merchant 4 via the network 
5 1, along with the payment, in step 48. 

It will also be recognized by those skilled in the art 
that, while the invention has been described above in terms 

=3. 

g of one or more preferred embodiments, it is not limited 

f; thereto. Various features and aspects of the above 

rj 10 described invention may be used individually or jointly. 

s 

Further, although the invention has been described in the 
context of its implementation in a particular environment 
and for particular purposes, e.g. a bill payment system, 
those skilled in the art will recognize that its usefulness 
15 is not limited thereto and that the present invention can be 

beneficially utilized in any number of environments and 
implementations. Accordingly, the claims set forth below 
should be construed in view of the full breadth and spirit 
of the invention as disclosed herein. 
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The present invention is not to be limited in scope by 
the specific embodiments described herein. Indeed, various 
modifications of the present invention, in addition to those 
described herein, will be apparent to those of skill in the 
5 art from the foregoing description and accompanying 

drawings. Thus, such modifications are intended to fall 
within the scope of the appended claims. 
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